Application messages are communicated between applications. Often, when an application message is transported, at some point in the chain of transport, the application message is encapsulated as an application-structured data payload in a message envelope. The message envelope may include message metadata, such as headers, addressing information, and transient message properties. The message envelope in combination with the application-structured data payload is often termed an “enveloped message”. Message envelopes permit the attaching of such message metadata without requiring that the sender, receiver, or intermediaries understand the application-specific data of the payload.
Distributed applications commonly use enveloped messages, such as with the Simple Object Access Protocol (SOAP) envelope format, to canonicalize and abstract the process of message transmission. These abstractions are not directly available in TCP/IP, HTTP, and other pervasively used networking protocols. Instead, networking protocols commonly transmit the application payload in a byte-oriented format.
For purposes of canonicalization and abstraction of such application payload, a message processor in the message processing pipeline conventionally examines the bytes received from the native networking protocol and attempts to construct an equivalent canonicalized enveloped message. However, the message processor may be unable to successfully complete this translation process for a variety of reasons. For instance, perhaps the network or application software is misconfigured or otherwise defective. In such cases, the message is termed “badly-formed”, “badly formatted” or “not well-formed”.
Conventionally, this failure in translation may be handled by discarding or rejecting the badly formatted message bytes. However, discarding or rejected messages may be impermissible according to the data handling rules of the distributed application. Even if permissible, discarding or rejecting message may have adverse impact on application performance.
An alternative conventional approach is use a different pipeline (i.e., a failure processing pipeline) if a badly-formed message is encountered. This failure processing pipeline is different than the normal processing pipeline that is used if a well-formed message is encountered. However, entering a failure processing pipeline requires designing, developing, and testing an alternative execution path to the standard message processing pipeline, which adds additional cost and complexity to the distributed application. Also, some scenarios require the application to coordinate rejoining the normal and failure processing pipelines, such as when successful message processing and error recovery activities must be coordinated by a common transaction.